1. Field of the Invention
This invention relates to detecting mismatches in mirror volumes and more particularly relates to detecting mismatches in mirror volumes of data storage devices containing count key data (“CKD”) tracks with variable-length records.
2. Description of the Related Art
Often sensitive data requires data storage systems with a high degree of reliability. Computing systems often include a primary system for storing data from hosts and a secondary system that includes a backup copy of the primary storage system's data. A mirror volume typically provides a backup copy of data that is intended to be identical to a primary volume's data and may be used in place of the primary volume in case of failure or may be used as a source of data to re-initialize a primary volume with the backup data. Peer-to-peer remote copy (“PPRC”) is a protocol used to mirror data on a secondary storage volume, typically at a remote site. The IBM Global Mirror, Global Copy, and Metro Mirror products are examples of peer-to-peer remote copy protocols.
When a PPRC or other mirror volume is initialized, a system may include an option to bypass making an initial copy of data on the secondary storage system when a system administrator believes that the secondary storage system contains a current copy of the primary volume to be mirrored. If the mirror volume on the secondary storage system is a complete copy of the primary volume on the primary storage system, after the system is initialized, the mirror volume may be kept current by copying updates to the secondary as the updates are copied to the primary. If, however, the mirror volume is initialized without receiving an initial copy of the primary volume and the mirror volume is not an identical copy of the primary volume, updates to the mirror volume may cause data corruption and other system errors. An update may include one or more files or may include only a portion of one or more files that have changed. A file or update may include one or more records.
Corrupt data may be a problem if updates are copied to data tracks on the mirror volume and the updates don't align with record boundaries. For example, if a computing system includes tracks formatted using CKD tracks with variable-length records and the primary and mirror volumes are not identical, an update to a particular record or group of records on the primary volume may not align with records on the mirror volume. Copying the update to the mirror volume would corrupt records on the mirror volume copied over by the update and would cause errors. The errors caused by the mismatch of data on the primary and mirror volumes may be severe and may require the secondary system to be unavailable or to reboot, and is very undesirable in a system requiring high reliability.
The TotalStorage DS8000 series (model 2107), DS6000 series (model 1750), and Enterprise Storage Server (“ESS”) (model 2105) storage systems from IBM are all examples of systems with data storage devices, such as hard disk drives, formatted using CKD tracks with variable-length records. IBM's Fiber Connectivity (“FICON”) and Enterprise System Connection (“ESCON”) protocols are examples of protocols that use CKD tracks with variable length records. IBM's system Z and system 390 computers are examples of processors that use FICON and ESCON protocols to talk to CKD tracks with variable length records. Hard disk drives with CKD tracks differ from typical fixed block length tracks commonly in use today in that the CKD tracks may have records with lengths defined by a user. Each record includes a count field, an optional key field, and an optional data field. A count field includes information about the length of the key field and data field of a record.
CKD tracks may be regular or irregular. A disk with regular tracks includes records with CKD fields that are the same length for each record on the track. Regular tracks may be described by Track Format Descriptor (“TFD”) metadata describing CKD field lengths assigned to a particular track. TFD metadata can be used to locate a particular record on a track. TFDs may also be sent along with an update and compared with TFDs on a secondary data system to determine if there is a mismatch of data format on primary and secondary storage systems. Typically a record occupies an integral number of sectors.
Irregular tracks contain records with CKD fields of varying length on a track. For example, an irregular CKD track may include one record of 4 sectors adjacent to another record of 6 sectors. Since each record in an irregular CKD track may be of a different length, a TFD is insufficient to describe the records because a TFD only describes one key field length and one data field length. For a regular CKD track, a TFD is sufficient because all key fields on the track are the same length and all data fields on the track are the same length. For an irregular CKD track, metadata that describes the field sizes for each record is used to describe record locations and sizes. The metadata may be in the form of a cache record control block (“CRCB”) is placed in sector 0 of each track of a disk with irregular CKD tracks. Typically, record 0 is a fixed length, usually 48 bytes, and occupies a portion of sector 0 of each track. The CRCB is typically a table occupying an unused portion of sector 0 and contains information such as the starting sector and the size of the key and data fields of each record on the track.
The CRCB contains sufficient information to detect if a record on a primary volume aligns with a record on a mirror volume. However, transmitting a CRCB along with an update to a secondary storage system containing a mirror volume is undesirable due to the size of a CRCB and the related performance degradation caused by transmitting the CRCB. In addition, transmitting a CRCB may cause compatibility problems if, for example, a secondary storage system was not expecting a CRCB and received one along with an update.